Skip to main content

Secure Boot – Overview, Risks, and Handling of Legacy Systems

1. What is Secure Boot?​

Secure Boot is a security mechanism that ensures a device starts only with trusted, non-tampered software.
Already during power-on, all boot components are cryptographically verified.

In short:

  • Secure Boot verifies what is allowed to start
  • If a component is invalid or manipulated → the boot process is blocked

The goal is to prevent malware from becoming active before the operating system loads.

2. How does Secure Boot work? (Simplified)​

Secure Boot is based on a Chain of Trust:

  1. UEFI firmware starts
  2. It verifies the bootloader signature
  3. The bootloader verifies the kernel
  4. The kernel verifies drivers and system components

👉 Each stage may only start if it is cryptographically trusted.

3. What does Secure Boot protect against?​

Secure Boot primarily protects against:

  • Bootkits and rootkits (malware before the OS)
  • Manipulated bootloaders
  • Unauthorized operating systems
  • Persistent attacks that bypass traditional antivirus solutions

4. Secure Boot vs. TPM​

Secure BootTPM
Verifies what is bootedMeasures whether something has changed
Part of UEFISeparate hardware chip
Enforces trustEnables evidence (e.g. BitLocker)

➡️ Together they form the basis for Trusted Boot and Zero-Trust Endpoints.

5. What does “certificates are expiring” mean in Secure Boot?​

Secure Boot can be compared to an access control at a factory gate:

  • Every boot component has a digital ID (certificate)
  • This ID is valid only for a limited time
  • At boot time Secure Boot checks:

    “Is this ID authentic and still valid?”

When a certificate expires​

  • The ID is no longer valid
  • Secure Boot can no longer trust the component
  • The system will not boot (or only in a degraded mode)

⚠️ Important:
This happens at a fixed point in time, not gradually.

6. Which systems are most affected?​

🔴 High impact​

  • Old hypervisors
    • VMware ESXi (older major versions)
    • Hyper-V on older Windows Servers
    • Legacy KVM / Xen installations
  • Legacy Linux systems
    • Old RHEL / CentOS / SLES versions
    • Special appliances
    • Custom-built images
  • Industrial / OT systems
    • Production PCs
    • Edge devices
    • Machine controllers with UEFI
  • Offline or isolated systems
    • No patch access
    • No firmware updates

🟡 Lower impact​

  • Windows 10 / 11
  • Windows Server 2016+
  • Current Linux distributions
    ➡️ Certificates are usually updated automatically.

7. Why are hypervisors particularly critical?​

Hypervisors:

  • often run for 5–10 years
  • are rarely reinstalled
  • form the foundation of many virtual machines

➡️ A single affected hypervisor can impact dozens of VMs.

8. Can Secure-Boot certificates be installed afterwards?​

Firmware / BIOS / UEFI​

  • ❌ On older systems, usually not possible
  • Secure Boot keys (PK, KEK, db, dbx) are part of the firmware
  • Keys are provided by the hardware/firmware vendor
  • Without a supported key update mechanism, they are not replaceable

Conclusion:

Secure Boot cannot usually be retrofitted or repaired on old hardware.

Virtual Machines​

  • ✅ Yes, on the VM level
  • Each VM has its own virtual UEFI
  • VM Secure Boot is independent of host Secure Boot, if supported by the hypervisor

Requirements:

  • VM firmware = UEFI
  • Secure Boot enabled in the VM
  • Supported hypervisor (e.g. ESXi ≥ 6.x)

Windows​

  • Windows 10 / 11
  • Windows Server 2016+

➡️ Secure-Boot-relevant certificates are maintained automatically via Windows Update.

Modern Linux distributions​

These use a signed “shim” bootloader:

  • RHEL 7+
  • SLES 12+
  • Ubuntu 18.04+

➡️ Regular OS updates (shim + kernel) are sufficient.

Legacy Linux versions​

  • RHEL 6
  • CentOS 6
  • Old special-purpose distributions

❌ Not patchable for Secure Boot
➡️ Reinstallation or Secure Boot must be disabled.

9. Special case: VMware ESXi​

ESXi 5.x​

  • ❌ No Secure Boot in the modern sense
  • Boots via legacy BIOS or UEFI without Secure-Boot enforcement
  • ❌ No Secure-Boot certificate validation during host boot

Important clarification:

With ESXi 5.x, boot failures due to expired Secure-Boot certificates do not occur,
because Secure Boot is technically not active.

The real risks are:

  • End of Life (no security patches)
  • Known vulnerabilities remain unpatched
  • No modern platform security features
  • Compliance only possible with documented exceptions

Possible actions:

  • Continued operation with formal risk acceptance
  • Isolation / hardening
  • Planned migration

Newer ESXi versions​

ESXi VersionSecure Boot Capability
ESXi 7 / 8✅ Full (host & VM, hardware-dependent)
ESXi 6.7🟡 Limited
ESXi ≤ 6.0❌ Practically unusable

➡️ From ESXi 6.5 onward, Secure Boot becomes relevant, including certificate and key management topics.

10. Is Secure Boot mandatory everywhere?​

No – not retroactively.

Audit-safe rule of thumb​

SituationSecure Boot
New system✅ Required
New installation✅ Required
Major upgrade✅ Required
New hardware✅ Required
Unchanged legacy system❌ Not required
Isolated legacy system❌ With documentation

➡️ “New” is the decisive trigger, not the system’s age.

Short term​

  • Identify systems using Secure Boot
  • Capture versions and risks
  • Establish transparency

Medium term​

  • Upgrade to supported platforms
  • Use modern images and firmware
  • Establish Secure Boot as a standard

Exception cases​

  • Disable Secure Boot
  • Document and accept the risk
  • Define a transition or migration plan

12. Key message​

  • Secure Boot is a standard for new platforms
  • Legacy systems are handled risk-based
  • Not everything can be retrofitted
  • Migration is the only sustainable long-term solution

13. Key takeaways​

Secure Boot only protects the layer on which it is enabled.

Where Secure Boot is not active, Secure-Boot certificates cannot block booting.

Secure Boot is a target state – not a retroactive requirement.